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ABSTRACT 



A mechanism for gener ating customized graphical user 
i nterfaces for applications in an oDject-oriefited'e nvironment 
is disclosed. Su ch applications mav comprise Java beans, 
applets or components. The graphic user interface comprises 
a visual user interface, e.g. an action bar which co ntain a se t 
of buttons and menus as well as a set of widget and 
property/com mand panels, as well as a communicati on 
inteTface"through"whlch configuration and u ser responses a re 
exeh^B^e^-^trrthe-apT?licationsrThFr elaTionship between 
the-graphic use r interface and an arj plei_isJ3ased_on the 
applet-co mmunicating selection a nd use rjnte rf ace-inf or-m a - 
tion~To tne graphic user interface, andthegra phic user 
interface handling the user gesnires~by callin g methods on, 
specificiHterlaces oflhe appletrCommunicafionsJjetween 
the graphic user interface and applets occur over anj nfor- 
mation bus~arch~itecture referred to as the IhfoBus. 

21 Claims, 15 Drawing Sheets 
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CMFOCENTER USER INTERFACE FOR 
APPLETS AND COMPONENTS 

RELATED APPLICATIONS 

This application is the one of five U.S. patent applications 
filed on an even date herewith and commonly assigned, 
including: 

Ser. No. 09/222,489, by Douglas J. Wilson et. al., entitled 

"Method and System for Communicating Information 10 

Among Interactive Applications"; 
Ser. No. 09/222,201, by Douglas J. Wilson et. al., entitled 

"Method and System for Controlling Data Acquisition 

Over and Information Bus"; 
Ser. No. 09/222,494, by Douglas J. Wilson, et al, entitled ^ 

"Method and System for Retrieving Data Over an 

Information Bus"; and 
Ser. No. 09/222,467, by Douglas J. Wilson et. al., entitled 

"Method and System for Distributing Data Events Over 

an Information Bus". 20 

FIELD OF THE INVENTION 

This invention relates generally to improvements in com- 
puter systems, and, more particularly, to a user interface for 25 
use with computer systems. 

BACKGROUND OF THE INVENTION 

Numerous advances have been made recently to simplify 
the manner in which users interact with computer systems. 30 
For example, graphic user interfaces (GUI) have been cre- 
ated to provide visually intuitive means of interacting with 
a computer. In particular, GUIs such as that available in the 
Workplace Shell, part of the OS/2® operating system, 
commercially available from IBM Corporation, Boca Raton, 35 
Fla., and Windows GUI for the DOS operating system, 
commercially available form, Microsoft Corp., Redmond 
Wash., enable users to process and store data using graphic 
metaphors which resemble real life objects. Such interfaces 
have vastly reduced the level of sophistication and expert- 40 
ence necessary for users to interact in a meaningful manner 
with the computer system and, accordingly, have increased 
user productivity. 

Such graphic user interfaces, referred to hereinafter as 4J 
legacy GUIs, are somewhat static in their format and do not 
readily adjust to a user's task very well. As a result, 
applications are designed to work with the limits of the 
graphic user interface, rather than the graphic user interface 
configuring itself to the task performed by an application. 5Q 

One of the major developments in the field of software 
design has been the emergence of object-oriented technol- 
ogy. As explained in greater detail hereinafter, object- 
oriented technology enables the analysis, design and imple- 
mentation of software systems with intelligent, autonomous 55 
agents called objects. Such objects facilitate the design of 
modular software which more closely mimics the physical 
or logical entities within the real world. 

One of the more recent developments in object-oriented 
programming is the Java® programming language devel- 60 
oped by Sun Microsystems, Mountain View, Calif. The Java 
programming language is an object-oriented language, hav- 
ing many elements in common with the C programming 
language and C++ programming language, with additional 
modifications. The Java programming language has the 65 
benefits of an interpreted language in the performance of 
compiled code. To enable Java applications to execute on a 
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computer network, a compiler generates an architecture- 
neutral object file format, i.e. the compiled code is execut- 
able on many processors, given the presence of the Java-run 
time system. 

The Java languages enables developers to write custom 
applications called Java applets. When integrated into 
webpages delivered over the Internet, Java applets allow 
expert graphics rendering, real-time interaction with users, 
live information updating and full use of multimedia and 
instant interaction with servers over a computer network. 

The Java language and environment, including the Java- 
Beans specification provide mechanisms for the creation and 
management of small components whose function represent 
the building block to use in applications such as web 
applications. The term component as used in the 
specification, refers to a Java component which participates 
in a class definition and has a user interface. 

Object-oriented environments, such as the Java virtual 
machine (JVM) environment, facilitate the design of beans 
or applets, useful in a network environment. In a network 
environment much of the functionality of applications is 
stored not on the actual user's computing platform but is 
accessible through a computer network such as a LAN or a 
public network such as the Internet. As a result, there is a 
current trend for reducing the complexity not only of appli- 
cations and computer hardware architectures but also the 
interfaces used for computers which operate in a network 
environment. Accordingly, the legacy graphic user inter- 
faces used with prior computer architectures and operating 
systems are not suitable for use with the emerging field of 
network computers (NC) and applications such as beans or 
applets which execute thereon. 

A need exists, therefore, for a user interface which inter- 
acts with object-oriented applications, particularly in the 
JVM environment, which is capable of dynamically adapt- 
ing itself to the specific interface requirements of an applet. 

A need further exists for a user interface that is suitable for 
use with network computers and the dynamics of distributed 
computing and data communications in a network environ- 
ment. 

SUMMARY OF THE INVENTION 

The present invention provides a mechanism for adding 
graphical user interfaces to applications in an object- 
oriented environment. Such applications may compri se Java 
be ans, applets or components. The invent ive graphic user 
interface ret'erred to hereinafter as intoCenter comprises a 
visuaJ-useHrfler tace, e.g. an action bar wmcn contain a" s et 
of 'buttons - ana menus as well as a set of wid get jtn d 
p roper ty/CQfflMaflrJ"~r)anels , as weH~a5" a ' communication 
int erface through whicn conrlgurarion ana user responsesare 
exc hanged with a pple ts . TlTe^l at ionshirT Be twee rTtHe I nfo - 
Cente r and an ap p let is based on the applet communicating 
select ion and user interface in tormation^onhe'InfoCenter, 
ancTTh TlntoCenter handlmg7h"e~user-gestures-bv'callg !g 
met fjocts on specific interfaces of the applet. In the prese nt 
inven tion communications between the InfoCenter and 
applets oc cur over an information bus architecture re ferred 
to as the InfoBus , as_described h ereafter. 

According to one embodiment of the invention, a method 
for dy namically gen cl a lnig a usu intcrfate itr ainetwo rk 

CO mrftTter environme nt comprises the gtrprc nf rprpjyjnff an 

anno uncement of an object selection from an ap plet, que- 
rying the selection obje ct for a user interlac e description, 
disrH a^ring--an-actiarr"bar graphically based on "the~u$e p 
interface description, and responding to user selections. The 
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user interface may dispia^_additional-paxieJs_Qr„pop_ up 
graphic entities lFresi^nsejoj^^ 

item b y a user. IuTesponseto a user's selection to alter a 
property- of the ap picroT senB a_c omjaa nH in the . applet, th e 
user intufaic calls the" appropriate methq H nf the, class 5 
specified in t rie user lntert aceldescHption-sup plied by the 
applei. Uiilizin ^hese ,i Dt p rf fl<x's^ryt i^ i i^n a nmy Hyrp mi. 
cally configOTethelnf oCenterjiser interface with their o wn 
user interfafce-ctescfip tions and the user interface resp onse to 
user input and~" calls"the avail ah le„metho ds describe cPin the 10 
user interfaofciescription. 



BRIEFDESCRIPTION OF THE DRAWINGS 

The above and other features, objects and advantages of 
the invention will be better understood by referring to the 15 
following detailed description in conjunction with the 
accompanying drawing in which: 

FIG. 1 is a block diagram of a computer system suitable 
for use with the present invention; 2Q 

FIG. 2 is a conceptual diagram of the elements comprising 
the user interface in accordance with the present invention; 

FIGS. 3A-D illustrate the InfoCenter graphical user inter- 
face and its component elements in accordance with the 
present invention; 25 

FIGS. 4A-D illustrates the InfoCenter graphical user 
interface of the present invention as utilized with a browser 
application; 

FIG. 5 is a conceptual block diagram of the communica- 
tion path between the InfoCenter and an applet via the 30 
InfoBus in accordance with the present invention; 

FIG. 6 is a flow chart illustrating the process steps by 
which an applet interacts with the InfoCenter user interface 
of the present invention; 35 

FIG. 7 is a flow chart illustrating the process steps by 
which the invention generates a User Interface within an 
InfoBus system; 

FIG. 8 is a block diagram of the ActionDescriptorSet 
utilized in FIG. 7; and 40 

FIG, 9 is a block diagram of the Action Descriptor of FIG. 
8 according to the present invention. 
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FIG. 1 illustrates the system architecture for a computer 
system 100 such as an IBM PS/2®, on which the invention 
may be implemented. The exemplary computer system of 
FIG. 1 is for descriptive purposes only. Although the 
description may refer to terms commonly used in describing 
particular computer systems, such as in IBM PS/2 computer, 50 
the description and concepts equally apply to other systems, 
including systems having architectures dissimilar to FIG. 1. 

Computer system 100 includes a central processing unit 
(CPU) 105, which may be implemented with a conventional 55 
microprocessor, a random access memory (RAM) 110 for 
temporary storage of information, and a read only memory 
(ROM) 115 for permanent storage of information. A 
memory controller 120 is provided for controlling RMA 

A bus 130 interconnects the components of computer 
system 100. A bus controller 125 is provided for controlling 
bus 130. An interrupt controller 135 is used for receiving and 
processing various interrupt signals from the system com- 
ponents. 65 

Mass storage may be provided by diskette 142, CD ROM 
147, or hard drive 152. Data and software may be exchanged 



with computer system 100 via removable media such as 
diskette 142 and CD ROM 147. Diskette 142 is insertable 
into diskette drive 141 which is, in turn, connected to bus 30 
by a controller 140. Similarly, CD ROM 147 is insertable 
into CD ROM drive 146 which is, in turn, connected to bus 
130 by controller 145. Hard disk 152 is part of a fixed disk 
drive 151 which is connected to bus 130 by controller 150. 

User input to computer system 100 may be provided by a 
number of devices. For example, a keyboard 156 and mouse 
157 are connected to bus 130 by controller 155. An audio 
transducer 196, which may act as both 3 microphone and a 
speaker, is connected to bus 130 by audio controller 197, as 
illustrated. It will be obvious to those reasonably skilled in 
the art that other input devices, such as a pen and/or tabloid 
may be connected to bus 130 and an appropriate controller 
and software, as required. DMA controller 160 is provided 
for performing direct memory access to RAM 110. A visual 
display is generated by video controller 165 which controls 
video display 170. Computer system 100 also includes a 
communications adaptor 190 which allows the system to be 
interconnected to a local area network (LAN) or a wide area 
network (WAN), schematically illustrated by bus 191 and 
network 195. 

Operation o f compute r_systern 1 00 is generally co ntrolled 
and coordinated by operating system software, such as the 
OS/2® operating system, avauaoie irom International Busi- 
ness MaTrrine^ongir&&^ 



95 fro m Microsoft Corp., Redmond, Wash. The o perating 
system controls^allgcation.of^y^tem4"esourcesand^erforms 
tasks j uctTas processing scheduling, mem ory management, 
networking, and I/O services, among things. In particular, 
the operaTihg system residentin^ystern-memory-and running 
on CPU 105 coordinates the operation of the other elements 
of computer system 100. The present invention may be 
implemented with any number of commercially available 
operating systems including OS/2, UNIX Windows NT and 
DOS, etc. One or more applications 202, such as Lotus 
eSuite, commercially available from Lotus Development 
Corp., Cambridge, Mass., may be executable under the 
direction of operating system. 

In the illustrative embod iment, the elements of InfoCe nter 
GUI are~i mple"mented using an object-oriented progr am- 
mingiang uage and, such as the Java programming langu age 
techni ques, ine Jav a language i'q wp.l Uknnwn~an"d many 
articJesTodluix^ 

in detail. In addition, Java compilers are commer cially 
available4remr seve~rai vendors including Sun Microsyst ems, 

Inerr- MoTr n ^l" Vi^w , fa lit' ArmrHinply , fpj re ason s of 

clarity, t he details of the Java language the Jav a Virtual 
Machine, environment and the operation oi a Java-compiler 
wilI-<iot-be-disettss e d f iuthet in de ta il heieiii,-li uwever, a 
brief over view of object-oriented programming is set here- 
after foTTne reader s be nefit. As will be understood by tho se 
skilled-on-the— ait, Ubjecl-Onented Programming (OOP) 
technigjiesjrjyxily^th ^dcfiiiitiui l , creation, Use and de struc- 
tion of "objects" These, nhjects are. snfrwaj^_entities com- 
prising data elements, "or attributes', and meth ods, or 
functions, "wHicn manipulate the data elements. The 
attributesjmdj^laledjnct^ software as 

an entity and can be created, used and deleted as if they were 
a single item. Together, the attributes and methods enable 
objects to model virtually any real-world entity in terms of 
its characteristics, which can be represented by the data 
elements, and its behavior, which can be represented by its 
data manipulation functions. In this way, objects can model 
concrete things like people and computers, and they can also 
model abstract concepts like numbers or geometrical 
designs. 
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Objects are defined by creating "classes" which are not modify some or all of its inherited functions merely by 

objects themselves, but which act as templates that instruct defining a new function with the same form. Overriding or 

the compiler how to construct the actual object. A class may, modification does not alter the function in the base class, but 

for example, specify the number and type of data variables merely modifies the use of the function in the subclass. The 

and the steps involved in the methods which manipulate the 5 creation of a new subclass which has some of the 

data. When an object-oriented program is compiled, the functionality, with selective modification of another class 

class code is compiled into the program, but no objects exist. allows software developers to easily customize existing code 

Therefore, none of the variables or data structures in the to meet their particular needs, 

compiled program exist or have any memory allotted to InfoCenter Architecture 

them. An object is actually created by the program at in . . . ■ • , 

runtime by means of a special function called a constructor M used m r the f°U°«™g terms have the 

which uses the corresponding class definition and additional mean f f xt forth , b f ow -' T 1 * term Deskto P refers ' 0 | he 

information, such as arguments provided during object J*™? 16 e TkT^I ^ V , ° D a h COm P U ' er d f P 1 ^ 

, l ■ . * r *i • i_* . terminal of which the InfoCenter may be an integral part 

creation to construct the objec Likewise objects are thefeof The termJTocu s » refcrs t0 th * area of a d ^ cum P C nt 

destroyed by ^a special Junction called a ) destructor. Objects 35 where the users in^I lhear^ r- g r'«~ " ^ 

may be used by using their data and invoking their functions. the - c msorW-lasTl er^ refers to a. 

When an object is created at runtime, memory is allotted and geneHe-coTrtrorelement, such as a graphic button, slider, or 

data structures are created. othe r tKrtentr oniel e i utilized iu tlie panel o f a feraphi c user 

The principle benefits of object-oriented programming interface. I he term "InfoCenter" refers to the user interface , 

techniques arise out of three basic principles; encapsulation, 2 o including any associated menusT action bar, panels for the 

polymorphism and inheritance. More specifically, objects inven tive - " architecture ot tne present invention. The term 

can be designed to hide, or encapsulate, all, or a portion of, "Action Bar" ref ers to the area of the InfoCenter tha t 

their internal data structures and the internal functions. More provides quicK access to the most commonly used applet 

particularly, during program design, a program developer features, as well as access to menus. Trie j term "Action Item" 

can define objects in which all or some of the attributes and 2 5 refers to a hot-s pot on the action bar, that provides sin gle^ 

all or some of the related functions are considered "private" cliclcaccess to a command or action. The term "Quick Item" 

or for use only by the object itself. Other data or functions refers tcHrpop=Up palette ot choices from an action bar item, 

can be declared "public" or available for use by other The terrn^Main Menu Item" refers to a hot-spot o n the 

programs. Access to the private variables by other programs a ction bar or menu item that provides access to a pop-up 

can be controlled by defining public functions for an object 30 tex tual menu. The term "Menu Bar" refers to a shding"bT r 

which access the object's private data. The public functions that overla_y s_jurxirtioT^ei^ 

form a controlled and consistent interface between the additional menu access. The term "Pop-Up Panel" refers to 

private data and the "outside" world. Any attempt to write a panel that results from performin g an actton'that'require s 

program code which directly accesses the private variables additional user input or assi stance, op panel that dis plays 

causes the compiler to generate an error during program 35 the full propertieTfoTffieselective object, as we ll as multipl e 

compilation which error stops the compilation process and tabs r in~tEe event lhat~mere~are~too many pro perties-to be 

prevents the program from being run. displayed on a single panel. The term "Tab" refers to a panel 

Polymorphism is a concept which allows objects and for^snb-cate gurized p i upe i t ies M.a. p r orrertvrpanett:^ 

functions which have the same overall format, but which "Status Bar 1 refers to an area supplied by the netwo rk 

work with different data, to function differently in order to 40 com puter desktop i u whirh a ppInN rnn pnit mr^ri^r^r^flTTh 

produce consistent results. For example, an addition func- as "new mail received", "mail sent", and "connecting to 

tion may be defined as variable A plus variable B (A+B) and server". <c - 

this same format can be used whether the A and B are FJG*-24s-*-bIock diagram depicting an InfoCenter 210, 

numbers, characters or dollars and cents. However, the which is communicatively coupled to an assortment of 

actual program code which performs the addition may differ 45 applications 212-216. The applications include, for 

widely depending on the type of variables that comprise A example, a Java applet 212, a Java bean 214, and a com- 

and B. In this example, polymorphism allows three separate ponent 216. The number of applications is not duly limited, 

function definitions to be written, one for each type of nor must there be at least one each of the applet 212, bean 

variable, e.g., numbers, characters and dollars. After the 214, or component 216. Rather, an assortment of such 

functions have been defined, a program can later refer to the 50 applications are allowed to interact with the InfoCenter 210 

addition function by its common format (A+B) and, at when used to generate a customized graphic user interface, 

runtime, the program will determine which of the three The InfoCenter 210 and applications 212-216 communicate 

functions is actually called by examining the variable types. one with another via communications bus 218, which is an 

Poly morphism allows similar functions which produce InfoBus and operations according to the protocol described 

anal ogous results to be "grouped" in the program sourc e 55 in the InfoBus section below. InfoCenter 210 serves as a 

codFTo produce a more logical and clear program flow. user's interface generator to produce customized GUI's 

The third principle which underlies object-oriented pro- based on a designer's input as selected from features avail- 

gramming is inheritance, which allows program developers able to the designer. 

to easily reuse pre-existing programs and to avoid creating FIGS. 3A-D illustrate screen captures of an im piemen- 
software from scratch. The principle of inheritance allows a 60 tation of the InfoCenter in accordance with the present 
software developer to declare relationships among classes invention. FIG. 3 illustrates a Desktop 300 of which the 
and the objects which are later created from those classes. InfoCenter 320 is displayed thereon. InfoCenter 320 corn- 
Specifically, classes may be designated as subclasses of prises Action Bar 322, containing a number of Action Items 
other base classes. A subclass "inherits" and has access to all 324 and main Menu items 326. Selection of a Main Menu 
of the public functions of its base classes just as if these 65 item 326 results in a Pop-Up Menu of Quick-pick items 328. 
function appeared in the subclass. Alternatively, a subclass Quick-pick items 328 appear in a Pop-Up palette 330 of 
can override some or all of its inherited functioas or may choices from Action Bar 322. 



05/19/2003, EAST version: 1.03.0002 



US 6,469,714 B2 
7 8 

FIGS. 4A-D illustrate screen captures of an implemen- Wh en a user clicks on an item that provides a c cess Jo a 

tation of the InfoCenter in accordance with the present quick-pick control 328, a smaTTopimn ^ pnlrttr pnpn-iip^ 

invention as displayed in a web browser environment. FIG. inHiratinp^the-nrfrfiht sp.Terrinn aq jUn^fi ,iIm1 in PTG~ 3B. 

4 illustrates a desktop 300 of which the InfoCenter 320 is Clicking rm an np ti^TviffiTrTtt^p alc^^ app 



^-immediately applies 

displayed thereon. InfoCenter 320 cxapp«ses"thft^a c.tion bar 5 that option anrraismisscs the palette. Click ina^riside of the 

322, which co ntains a-nnmht^ of action items 324 and- main palette may disfflifia The paieite wiino m-fielectinp any option, 

me nu items"526. T hfiuiesktop 300 ^s essentially the same a s Focus-is itluiil^atojtfi--*PP^Cwhether or not the user 

that of the deskto^ OQ J Qf-H€T-3AzrDjm^asoorr^ chooses-s^metrrtngTnthe Quick-pick, 

feamre^jisiagah^same numberingToSe^itjo Fira URL Jf aj^ anel is open when a ry^- p^ %2S U«-**ttrX the 

windpji^410 that is ut&ze^o^entein^ 10 pane l remains open, if not, the panel may be dismissed or 

file informa t i on , o r othcrd a ta re ii:ieva4-poijiting information dimmed. The Quick-pick panel may have the same edge 

as desir^LhjUhc-xiser. The-remaiqin g items illu strated in co i or ^ t he menu widget to help it stand out from the panel 

FIGS. 4A-D ^the^arne_as_those described in detail with underneath. In the illustrative embodiment, the InfoCenter 

respect to FIGS. 3A-D. 320 displays panels which allow a user to set properties or 

The InfoCenter provides a full UI access to all commands 15 complete selected commands. In the InfoCenter, 320 most 

and properties of applets including combined action bar panels are modeless, allowing users to click outside the 

menu access and pop-up panels. The InfoCenter user inter- panel and perform other tasks. Exceptions may include 

face fits on a network computer desktop, e.g. at the bottom, messages in the current applet which require user acknowl- 

but may be designed to float or be repositioned on the edgment. 

desktop. Action items 324 that toggle on or off show the 20 

current status of the selected object. Examples include Bold, Automatic Apply 

Italic and Show/Hide Drawing Tools in the Presentation p rt b cfa tQ reflect ^ cmcni afld 

Graphics applet. If the selection contains mixed properties, automatically apply changes as made. If the selection con- 

the state based on the settmgs at the beginning of the tains mixed properties, the state based on the settings at the 

selection may be shown. 25 beginning of tfae stlccXion are shown For example) in a 

InfoCenter Elements spreadsheet applet, the properties for the cell in the upper 

leftmost corner of the selection are shown. 

The action bar 322 exposes and provides one-click access 

to the most common applet features of an applet. It also 30 Context-Sensitivity 

provides access to menus. Different action bar items may Wnen a user moves the cursor mym ^ an object such as a 

produce different behaviors, such as: paragraph or a range of cells, the controls in the InfoCenter 

1. initiating an action with a single click, such as Cut or Property panels update to reflect the new state. If, however, 
Bold; the user chooses a different object type, such as going from 

2. displaying access to a palette of specific settings, such 35 a paragraph to a table, the property panel may automatically 
as a color palette or alignment options; dismiss itself. 

3. launching the user into a specific task, such as the Such context-sensitivity also applies to selection Based 
scheduling of a meeting or the invitation of guests in a command panels too. For example, if a user is working on 
calendar applet; a table and has brought up the Insert Multiples, rows and 

4. presenting an entire properties or command panel, such 40 columns > e -S- command panel, clicking off the table will 
as Save, or Print; dismiss the P aneh 

5. providing access to menus. Panel Management 
To ensure that each applet's action bar items fits within 

the desired size available on the desktop, a translation table 45 Some panels may close after performing actions, such as 

for the names of commands for each applet may be produced print > wmle others may remain open, su ch as Fi nd/Repjace. 

for use with international products requiring translations of Such intera ction is specified on a panel by pan elbasis in the 

command names. mdiviauaTapplet UI Specifications. If a panel is visible ^ nd 

In the contemplated embodiment, each applet is respon- the jiser perform an action that disT^ y^noJhe r_panel, the 

sible for ensuring that the standard English version of the 50 second panel replaces the first paj ieL_Wh eii_the seco nd j>anel 

action bar accommodates all supported languages, which is clo sed, no pan els^aie-vjsibkfc ' 

typically requires more width. The action bar is context 

sensitive, allowing context switching within applets. The Default Data 

different contexts, as well as actions available within each Data for the File Save and File Open panels, as well as 

context, are specified in the individual applet UI Specifica- 55 certain application-specific panels, as defined in each appli- 

tions. cation specification, are remembered from the last time a 

A . ¥ „ panel was visible. If a user changes settings on a panel and 

Action Bar Items Showing State and Availability tnen performs that action or switches to another panel, the 

Action Ite ms 324_that toggle on or off may show the changed settings are still visible the next time that panel is 

cur re^TsTaTuTof the selected object, examples in clude Bold 60 access. If the user cancels the panel, the values revert to their 

and Italic, as illustrated m FIG. 3D. Action items "5241EaTare stalic default the next time the panel is accessed. 
not~ ayattaDte in tne current context are dimmedTH For 

example, Past e should be dimmed when nothing is on Oie Menu 

clipboard. Menu commands mat are identical to action items The InfoCenter also provides an organized, cate gorized 

may miff erthi bcljaviorof the correspondtng^ctior fitem. If 65 mean s'ftfpresenting a ll the leaiures ot' an applet, i tems .are 

the Paste Xcti on Item is dimmed because nothing"is "rjirthe g rouped in the action Par by menu structure. A MaiTMe nu 

clipboard, therFaKte f menu itp.m niav also be dimmed. Item 326 label appearsabove the action item group. ClicTang 
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on the Main Menu Item 326 label pops up the full list of 
items tor that menu ^u^ssiliustFafecl in FIG. 3~C. Cliclang* 
on a'menu item peitorms tne speafiecl "cbmmanclrClicIahg 
anywh^TroulsigrThe Infol^TeT^is lnisseT ^tn Tmenu witfc 
ourperforming an actiofi. ~Ch*ckingl)ir another Main Menu 
Item ^32 6" dismisses th e open menu_3 30_and displays, that 
menu ' Clicking on an Action Item_d istnisses-the-meim_and 
performsJl ^pecifi etlActiQnite m^Focus is returned to the 
applefT wEether or not the user chooses something in the 
memiTIt a menu item does not apply, such as the~P aste 
comman dT when nothing is on the clipboard, it w ill be 
dimmeo vas will tne identical Ad inn Item on the actfoTT bar. 
A ecrrffmand can either: " " 

p erform an immediate action, such as Cut or Cop y; 

display a panel to allow you to begin to co mplete the 
comman d, such as Find/Replace, Save, or FfinlH5T 

display a properties panel, s vh a<j Font Pr^pgrTfrs 

Aft^r-T^^ing fl r»mman^ from th" Mppu Bar n the menu 

bar returns to itsclnsed ^afe r and the specified mmmanH is 

performed- 5 *" 



Messages and Alerts 



Help 



General InfoCentcr Interaction 



10 



15 



20 



' Context Sensitivity 

The Menu Bar may be context sensitive, allowing context 
switching within applets, as well as between applets in 2 5 
future releases. The different contexts, as well as what 
actions are available within each context, are specified in the 
individual applet UI Specifications. 



30 



35 



A limited number of different types of messages and 
notifications are included in the Info Center. The messages 
and notifications fall into the following broad categories: 

Modeless floating window messages 

Modal floating window messages 

Notification/Status messages 

The last type listed, Notification/Status messages such as 
"You have new mail" and "Calculating . . .", appears in the 
message area of the NC Desktop. In addition to message 4Q 
notifications, there are four states for icons in the eSuite 
Desktop open task list: Normal, Busy, Error, and Notifica- 
tion. 



45 



Help is accessed from the action bar using a "?" icon 332 
as the right-most item as shown in FIG. 3. When the user 
chooses the Action Item, a pop-up menu appears. From 
there, he or she can go directly to a context-sensitive Web 
page at Lotus though it cannot be sensitive to selections on 50 
the action bar or a Contents page for that applet's help. 
Access to the About Box including proprietary notices is 
available from the "V menu. 



55 



Resizing 

If the work area is expanded, white space is added to the 
right side of the action bar and to the right of all panel/dialog 
controls that are not anchored to the right-hand side of the 
panel. When working in a screen resolution of 800x600, the 60 
work area may be 640x547. When the work area is 
expanded, the work area will increase its width by 112 for 
a total of 752 pixels. Panels may be 640 pixels wide and 
anchor particular controls to the right-hand side of the panel. 
Tabs may be anchored on the left, as well. When the panels 65 
resize, the controls that are anchored will- remain tied to the 
right side of the panel. 



Scrolling 

Applet space scroll bars and workspace may end above 
the InfoCenter thereby reducing the amount of applet work- 
space when a panel has been opened. When an InfoCenter 
panel pops up, the applet shrinks its vertical space to make 
room for the panel. When no panels are open the scroll bar 
ends above the action bar. 

InfoBus Architecture 

The InfoCenter communicates with applets executing in 
the same environment via an information bus architecture 
referred to hereafter as the InfoBus. The architecture of the 
InfoBus is described in the publicly accessible specification 
entitled InfoBus Specification 1.1.1 available from Lotus 
Development Corp. and is the subject of the copending U.S. 
patent applications referenced in the Related Applications 
Section of this application. It is described in part hereafter 
for the reader's benefit with reference to FIG. 5. The InfoBus 
architecture enables developers to create a new class of 
dynamic applications in which data exchange is based on 
information content. For example, a single database access 
component can offer the InfoBus information from a wide 
variety of databases. The information on the InfoBus is 
dynamically tagged by its content. Data consumers such as 
a charting or reporting component can receive the data based 
on the dynamic tags. In addition, in the contemplated 
embodiment, the InfoBus architecture provides mechanisms 
for transmitting highly-structured data such as keyed rows in 
a collection. As a member of the InfoBus, any exchange 
information with any other component in a structured way. 
Simple items like strings and numbers and complex items 
like lists, arrays and tables can be tagged over the virtual 
information bus. For example, a component could provide a 
user interface that allows users to select an item, such as an 
account number, and publish the selected item on the Info- 
Bus. In response, a second component lists names for the 
account number, could look up information from an external 
database and publish it in a table of results over the InfoBus. 
Finally, a third component, such as a spreadsheet, could 
access this result table and display it or use it for further 
analysis. Developers build InfoBus applications by present- 
ing a set of cooperating components in a design 
environment, such as a HTML document or a webpage. The 
components communicate via the InfoBus making it pos- 
sible to divide the application into manageable pieces. 

The InfoBus interfaces allows application designers to 
create "dataflows" between cooperating components. In 
contrast to an event/response model where the semantics of 
an interaction depend to an understanding an applet-specific 
event and responding to that event with applet-specific call 
backs, the InfoBus interfaces have very few events in an 
invariant set of method calls for all applets. The semantics 
of data flow are based on interpreting the contents of data 
that flows across the InfoBus interfaces as opposed to 
responding to the names of parameters from events or names 
or parameters of callbacks. 

The components which comprise the InfoBus architecture 
can be classified as data producers, data consumers and data 
controllers. Data producers respond to requests for data from 
consumers. Data consumers comprise components inter- 
ested in hearing about any new data sets that enter the 
database environment. Data controllers optionally regulate 
and redirect the flow of data between data producers and 
many consumers. 

Any Java component can connect to the InfoBus archi- 
tecture. The unique InfoBus context identifiers established 
for a component in the InfoBus for the components contexts 
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is returned. Once a component establishes participation in an 
InfoBus, all InfoBus notifications arrive via standard Java 
event mechanisms. In the contemplated embodiment, ren- 
dezvous of data to be exchanged are asynchronous. Data 
producers announce the availability of new data as it 5 
becomes available. For example, completion of a URL read, 
or completion of calculation. Data consumers solicit data 
from producers as are needed, for example, at applet 
initialization, redraw, etc. Different data producers manage 
different types of data while data consumers may receive 1Q 
such data in simple or complex way. To accommodate the 
needs of both data producers and data consumers, the 
InfoBus architecture defines a number of data access inter- 
. face. These interfaces given the data consumer choices about 
how to navigate through the data provided by a data pro- jg 
ducer. Producers choose the most appropriate access types 
and publish the data as an item of that type, while data 
consumers may use the data as the type specified or as a 
supertype. For example, a spreadsheet component might 
publish a name arranged as an Array Access data item. One 
consumer might process this data using ArrayAccess 
because this is the best match for its needs while another 
data consumer would choose the super type collection 
access, as explained hereinafter. 

As such, the InfoBus architecture of the present invention 25 
adds additional features required for more dynamic data 
exchange. For example, where communication is driven by 
the content of the data and where the nature of the data to be 
exchanged is determined at run time. The InfoBus architec- 
ture is complimentary to and extends the Java Beans envi- 3Q 
ronment by providing a set of enhanced interfaces that Java 
Bean components can use to share and exchange dynamic 
data. 

The InfoBus architecture itself is defined by a class 
definition which includes the data items and methods 35 
described hereinafter. One or more instances of an InfoBus 
may reside on a computer system, which, in the illustrative 
embodiment, comprises a Java virtual machine environ- 
ment. A class implements the InfoBusMembcr object to join 
the InfoBus, in preparation for receiving events about data 40 
on the bus. 

Applets can implement InfoBusMember using methods 
provided in the InfoBusMemberlmpl class to completely 
support InfoBus membership, the methods in this helper 
class use the class InfoBus methods for their implementa- 45 
tion. For example, InfoBusMemberlmpl .joinlnfoBus calls 
one of the static open( ) methods on the InfoBus class to find 
or create the required InfoBus instance, then calls join( ) on 
the instance to become a member. 

Applets may use the default InfoBus when running out- 50 
side of a builder environment. One of the open( ) methods 
takes a Component argument which is used to calculate the 
default bus name from the "docbase" of the applet. 
Therefore, the component must either be an applet itself, or 
have an applet in its AWT containment hierarchy so that we 55 
can traverse upwards to the applet. The caller itself need not 
be such a component, but it must be able to supply one. 

An applet builder environment needs to be able to open an 
InfoBus instance without necessarily joining it and telling 
the applets it contains to talk on that bus. Rather than using 60 
the default InfoBus for a component context, it will be 
handier to supply a name to be used for creating the InfoBus 
instance; a variant of the open( ) method allows the caller to 
pass a String that specifies the name of the required bus. In 
this case the builder environment has no particular 65 
requirements, i.e., it need not be an applet, because the 
"docbase" is not required. 



Both open( ) methods return a reference to the InfoBus 
instance that satisfies the request. This instance is used for all 
future communication to the InfoBus. For example, to 
become a member of this bus, the member simply calls the 
join( ) method on the returned instance, and leaves by calling 
leave( ). 

Membership is typically established during class initial- 
ization before the start( ) method is called. 

InfoBus Event Listeners 

InfoBus components must listen for events to discover the 
availability or revocation of Dataltems, or to hear requests 
for named Dataltems, or both. The way an InfoBus compo- 
nent uses events identifies it as cither a Data Producer or a 
Data Consumer. A component can be both a Data Producer 
and a Data Consumer, for example it could filter data from 
a Data Producer and supply it in a new form for a Data 
Consumer. 

The distinction between a consumer and a producer class 
is reflected in the type of interface(s) class implements, e.g., 
one or both of InfoBusD ataConsumer and 
InfoBusDataProducer, and how the class registers itself with 
the InfoBus, i.e., by calling the addD ataConsumer or 
addDataProducer methods, or both. 

Data Consumers 

A data consumer is an InfoBus component that listens for 
the availability or revocation of Dataltems, and/or requests 
Dataltems by name. The interface InfoBusD ataConsumer 
defines the methods for handling InfoBusItemAvail- 
ableEvent and InfoBusItemRevokedEvent notifications. The 
Data Consumer determines whether it is interested in the 
event by inspecting the Dataltem name in the InfoBusEvent 
object. An accessor method, 

InfoBusEvent. getDataltemName, provides a String identi- 
fier for the data. 

Dataltems can be requested by name by calling a find 
method in the InfoBus class. Data Consumers are permitted 
to issue data requests without having received a Info- 
BusItemAvailable Event. The requesting Data Consumer 
will simply get a null result if the requested data is unavail- 
able from any Data Producer. Such a blind request is often 
required when a Data Consumer initializes, in case an 
available event on the InfoBus was sent before the Data 
Consumer had completed initialization. 

A data consumer may also implement the Dataltem- 
ChangedListener interface. After rendezvousing success- 
fully and receiving an initial Dataltem, the consumer reg- 
isters for change notifications via the 
addDataItemChangedListener( ) method on the Dataltem. 
When the producer of the data makes subsequent changes to 
the Dataltem, the Dataltem send a DataltemChangedEvent 
to all registered listeners. As a Dataltem may itself contain 
a hierarchy of other Dataltems, the DataltemChangedEvent 
is received for the "top-level" Dataltem associated with the 
initial rendezvous name. 

Data Producers 

Any InfoBus component may function as a Data Producer 
providing the appropriate interfaces described herein are 
implemented. Essentially, data Producer is an InfoBus com- 
ponent that responds to requests for data from Data Con- 
sumers. Data is requested from a Data Producer by calling 
the findDataltem method on the InfoBus class. The find 
Dataltem method takes the name of the desired data and 
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solicits data from all bus listeners by calling the requires no programmatic changes to either Data Producers 
requestDataItem( ) method on each InfoBusDataProducer or Data Consumers. If one or more Data Controllers are 
registered with the InfoBus. If the Data Producer cal fulfill registered on the InfoBus, events arriving on the bus are 
the request, it responds by returning a reference to a class distributed only to the Data Controllers. The Data Control- 
implementing the Dataltem interface. 5 lers then assume responsibility for identifying the potential 
Another role of a data producer is to announce data Data Consumers of each event and distributing the Datalt- 
availability or deletion by sending InfoBusItemAvail- ems 10 them directly. 

ableEvents or InfoBusItemRevokedEvents methods to the Data controllers are potentially quite complex, and may 

InfoBus. The InfoBus then distributes these events to all keep track of Data Producers which have offered particular 

InfoBusDataConsumers by calling the dataltemAvailable 10 Dataltems, and, of Data Consumers that have requested 

and dataltemRevoked methods. Dataltems, in order to provide late binding of producer to 



consumer. 



Data Items 



Data Exchange Process 



In the illustrative embodiment, Dataltems are Java obiects * c * £ t» i r j i - 

. • , 4 . c l ip» . * . . t r J ™ 15 The InfoBus protocol for data exchange consists of the 

that implement the javax.infobus.Dataltem interface. The , r i\ w L u- T . n 

j r t> - j j • i A c «i 4 „ . t steps of 1) Membership, i.e., establishing InfoBus partici- 

InfoBus standard provides a set of data access interfaces K *\ T • * • c \ * * £\ « j 

u- u * j rx * ¥* i . . j £ * pation; 2) Listening for InfoBus events; 3) Rendezvous on 

which extend Dataltem in order to provide for retrieval or f, , ' ; , * , VT . . i , , 

• r *u r\ * i» » * . me data to be exchanged; 4) Navigation of structured data; 
navigation of the Dataltem s content. , « n A . , r & 7 & ri , , , , ™. 
° and 5) Retrieval of an encoding of the data value. This 
Creation of the Dataltem objects with access interfaces 20 process wiU be described in greater detail hereinafter, 
does not require that the data be retrieved provide access T 4 , .„ „ . T 
. - £ 1 *u c y\ * t * u- . In the illustrative embodiment, any Java component, 
interfaces. By keeping the creation of a Dataltem object . , T c * t /. *l t r t» l 
, f o j mcluding the InfoCenter, can connect to the InfoBus by 
cheap, a consumer can expect to request the item only to , * . T r n fcJf , t . . . T - ' 
•* **rijc * e *u^r f ui u- * • lmplementmg an InfoBusMember object, obtaining an Info- 
discover its MIME type from the Transferable object in « j i_ • , 6 . . lL 
a * a -a u *u * ** a ' a '* a wu * Bus mstance, and having the InfoBus member join the 
order to decide whether to use it or discard it, and expect that 25 • ♦ * .u t * u ^ 1 * t> -a 1 *u * 
*u- -ii 11 u * ■ 1 * * mstance of the InfoBus. The InfoBus provides a class that 
this will all be fairly fast. . ^ , . - , iL , , ^ j r 
' supplies an implementation for each method defined for 
Only objects that implement the Dataltem interface may InfoBusMember. 

be passed on the InfoBus. In the illustrative embodiment, for ^ . • t . u f T c « 

j » . 1 ^ j , ^ ■ ™ . Once an object is a member of an InfoBus, it can receive 

direct retrieval of data content as a simple String or Object, ^ notifications via the standard Java event mechanisms> 

the ImmediateAccess subinterface of Dataltem is provided. 30 under5tood by ^ {q ^ artg TwQ listener afe 

A Dataltem can be retrieved as a String or a Java object. - defined to support two basic types of InfoBus applications. 

Java objects are typically object wrappers for primitive types A Data Consumer can receive announcements about data 

such as Double or instances of other core classes such as availability by adding an InfoBusDataConsumer listener to 

InputStream. Little specialized understanding of data format tne InfoBus via the addData Consumer method. Similarly, a 

on the part of the data consumer is required. For complex 35 Data Producer can receive requests for data by adding an 

^interpretations of underlying data, the Dataltem provides InfoBusDataProducer listener via addDataProducer method, 

an optional method that returns a Transferable object, which ^ app i et can serve as both a consumer and producer of 

exposes the Dataltem. data> f or example in a filtering application, by implementing 

With the InfoBus Architecture a collection of Dataltems ^ both types of event listeners, 

can be passed as a single Dataltem, using one of the Listeners are normally added during the processing of the 

following interfaces for navigation of a collection: s tart( ) method, or its equivalent, and removed during the 

CollectionAccess, ArrayAccess, KeyedAccess, DbAccess, processing of the stop( ) method. With this technique, 

and RowsetAccess. Dataltems may optionally implement InfoBus member to stop receiving events when the page it 

both a collection interface and an ImmediateAccess inter- ^ is 0 n is inactive. 

face. From such a data item, simple data can be obtained by 45 , n the in ustrative embodiment, Data Producers 

asking for one of the immediate renderings, and more "announce" the availability of new data as the data becomes 

detailed information can be obtained by navigating the data readv ^ completion of a URL read, completion of a 

item using the implemented collection interface. - calculation, etc. Consumers solicit data from producers as 

InputStreams are considered single-valued items and 50 they require that data, i.e. applet initialization, button event, 

could be presented in an ImmediateAccess object. The intent etc. With InfoBus architecture, the rendezvous is by the 

of the InfoBus, however, is to impose structure on the data, name of the data. The application designer designates the 

in an effort to make the data comprehensible to the widest names for data items that can be exchanged over the 

audience of data consumers. Some types of InputStreams, InfoBus. 

however, like multimedia streams that are "played" by the 55 Data Producers and Data Consumers implement some 

recipient, will not lend themselves to such formatting. mechanism for the application designer to specify Data Item 

n r names for rendezvous. For example, in a spreadsheet 

a a n ro ers component, the user can "name" ranges on the sheet. Such 

In the illustrative embodiment, the InfoBus architecture name is a natural mechanism for naming data that can be 

may optionally implement Data Controllers. The role of a 60 exported by the sheet in a role as a data producer. Similarly, 

Data Controller is to play traffic cop on the InfoBus. a chart component needs a parameter telling it what named 

Essentially, a Data Controller is an optional component that data should be displayed in the chart, 

exists between any Data Producer and its Data Consumers. Different Data Producers often use different internal rep- 

The Data Controller regulates or redirects the flow of data. resentations of data that is superficially similar. For example, 

In the presence of a Data Controller, individual Data Pro- 65 a spreadsheet and a database both deal with tables, but store 

ducers and consumers do not talk to each other directly, but them quite differently. In a spreadsheet, the table of data 

instead communicate through the third -party controller. This might be represented as the output of a calculation, such as 



05/19/2003, EAST version: 1.03.0002 



US 6,469,714 B2 



15 



16 



a matrix transpose, or as an array of formulas, while in a 
database the, same information might be represented as the 
result of a join query. 

A Data Consumer, however, should not need a detailed 
understanding of the data producer's internal data structures. 
A charting component should be able to draw a chart of a 
table from either a spreadsheet or a database, whenever the 
table makes sense as a chart. In practice, this sort of 
information sharing requires a consumer and producer to 
agree on a common encoding of the data. 

Info Center/Component Communications 

Utilizing the InfoBus architecture described previously , 
the InfoCenter of the present invention communicates with 
the applets in the same environment. As an InfoBus member, 
the InfoCenter may act as either a data producer or a data 
consumer. The method by which an applet and the Info- 
Center interact over the InfoBus comprises the following 
steps: 1) the applet announces a Selection Context containing 
a Selection via the InfoBus; 2) the InfoCenter hears about 
the SelectionContext, retrieves a Selection and queries the 
Sselection object for a user interface description; 3) the 
InfoCenter displays an ActionBar based on the UI descrip- 
tion; 4) when a user clicks on a button or menu item, the 
InfoCenter may display additional UI e.g. panels or popup 
widgets; 5) and when the user clicks on something which 
alters an applet property or sends a command to an applet, 
the InfoCenter calls a setProperty or doCommand method on 
a class specified in the user interface description. 

This process is illustrated with reference to the flowchart 
of FIG. 6. and the block diagram of FIG. 5. FIG. 5 illustrates 
conceptually an InfoBus 500 with two InfoBus members 
502 and 504. The InfoBus exists in a Java virtual machine 
(JVM) environment. For purposes of illustration, data pro- 
ducer 502 is assumed to be an applet while data consumer 
504 is assumed to be the InfoCenter module. Once InfoBus 
members 502 and 504 enroll with the InfoBus instance 500, 
they are free to exchange data items as previously described. 
The interaction between a InfoCenter module 504 and an 
applet 502 occurs with reference to the process of FIG. 6. 
The process by which the InfoCenter interacts with an applet 
begins with Step 600 where the InfoCenter 504 becomes a 
member in an InfoBus instance, in a manner as described 
previously. Next, the InfoCenter listens for specific named 
events, particularly the announcement of an object selection 
by the applet, i.e. data producer 502, as illustrated by 
decisional step 602. If such an announcement is received, 
the InfoCenter module 504 queries the selected object about 
the user interface requirements, as illustrated by Step 604. 
Next, the applet 502 transmits to the InfoCenter module 504 
a description of the user interface associated with the 
selected object or a reference thereto, as illustrated by Step 
606. In response, InfoCenter module displays the appropri- 
ate user interface action bar and associated elements, as 
illustrated in Step 608. When a user clicks on a Widget or 
menu item in the InfoCenter, the InfoCenter displays addi- 
tional panels, menu items or pop-up widgets, as applicable. 
If the user selects a property which alters the applet or sends 
a command to the applet, as illustrated by decisional Step 
610, InfoCenter module will call the appropriate method for 
the class specified in the user interface description upon 
receipt of such selection or command by the user,* as 
illustrated by Step 612, FIG. 6. For a selection which alters 
the property of an applet, the InfoCenter will typically call 
the set property method while the transmission of a com- 
mand to the applet results in the InfoCenter calling the 
doCommand method. 

Utilizing the process illustrated in FIG. 6, the changes to 
the user interface required by an applet are essentially 
decoupled from the InfoCenter module itself, enabling the 



InfoCenter to be dynamically reconfigured according to the 
requirements of a specific applet. The design requirements 
for an applet in order to utilize the functionality of the 
InfoCenter are set forth below. 

5 

Applet Design Requirements 

FIG. 7 is a flow chart conceptually illustrating how a 
graphical user interface is provided via the InfoCenter in 
accordance with the illustrative embodiment. Initially, 

10 applets first implement a set of GUI panels, as illustrated in 
Step 700. Next, the applets announce selection data to the 
InfoBus at startup, on selection change and when focus is set 
as illustrated in Step 702. The applets then provide a 
selection object that implements the selection interface, as 

is illustrated in Step 704. The applets create a set of user 
interface description records, as illustrated in Step 706. 
Finally, the applets implement a set of commander and 
UlCommander classes, which is shown in Step 708. 
The above process is described hereafter in greater detail. 

20 In step 700, applet designers create UI panels using a visual 
interface builder such as Bongo, commercially available 
from Marimba, Inc., Mountain View, Calif. , and a set of 
widgets provided by the applet. Standard Bongo widgets 
may be used for panel widgets that are not interactive (e.g. 

25 label widgets). However, if the applet needs to get or set a 
widget value, a Lotus-specific widget may be used. 

Widgets are accessed in code via their Name property. 
The name field is set in the widget property panel when 
creating the panel in Bongo. This name, called the Property 

3Q Id, can be set by the designer or added later by an applet 
developer. Property ids can be any string, as long as the 
commander code for the panel can interpret that value. 
Usually, property ids are defined as a static member vari- 
ables in the associated commander class. The Commander 
interface method, getlDFromString, is called by the Info- 

35 Center code to translate the name to an integer id. 

In step 702, applets provide selection information to the 
InfoCenter via the InfoBus. When an applet starts up, it 
"connects" to the InfoCenter by announcing its current 
selection. This Selection is wrapped in a SelectionContext 

40 object and presented to the InfoCenter via an InfoBus 
Immediate Access object. The SelectionContext class is 
described below. Each time the selection changes, the applet 
updates the information on the InfoBus. This is the only 
connection mechanism between applet and InfoCenter. 

45 There is a helper function defined in LFCApplet for applets 
to use for announcing Selection information on the InfoBus. 

The public void assertSelection(Selection selection) 
method may be called by the applet on startup, each time the 
selection changes, and when the applet gets FOCUS. 

50 In the case of more than one Applet in an 
AppletContainer, each applet will announce its selection as 
described above. Each new announcement will change the 
InfoCenter context. When an applet is going away, LFCAp- 
plet will send the DATAREVOKED message for the Selec- 

55 tion Dataltcm. 

The SelectionContext class allows the InfoCenter to get 
the various parameters for a selection assertion. These are 
stored in an instance of this class before it is placed in a 
SelectionDataltem. The SelectionContext class is defined as 

60 follows: 

public class SelectionContext implements Cloneable 

{ 

public SelectionContext( ) 
public void release( ) 
65 public void setSelection(Selection selection) 
public Selection getSelection( ) 
public static final int SC_NEW_SELECTION«0; 
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public static final int SC_SAVE_STATB-1; 
public static final int SC_HIDE_UI=2; 
public void setType(int type) 
public int getType( ) 

public void setUserInterfaceState(UserInterfaceState 
uiState) 

public void setUserInterfaceState(ActionDescriptor ad) 
public UserlnterfaceState getUserInterfaceState( ) 
public void setActionDescriptor(ActionDescriptor ad) 
public ActionDescriptor getActionDescriptor( ) 
public void setICClientPreLoader(ICClientPreLoader 

clientPreLoader) 
public ICClientPreLoader getlCClientPreLoader( ) 
public int hashCode( ) 
public boolean equals(Object obj) 
public Object clone( ) 

} 

The SelectionContext( ) constructor is used to create a 
SelectionContext. 

The release( ) method is used to release any references 
held by this Selection Context. 

The setSelection( ) and getSelection( ) methods are used 
to manage the Selection interface held by this Selection- 
Context. 

The sctType( ) and getType( ) methods use ints with the 
following values to control how the InfoCenter interprets the 
selection made: 

The SC_NEW_SELECnON is the default type of 
Selection held in this SelectionContext, and indicates a new 
selection (either with UI State or without). If made with a UI 
state, the InfoCenter restores the UI State as a new selection. 
If made without UI state, the InfoCenter queries the Selec- 
tion (obtained via getS elect ion on this object) for a new user 
interface representation. 

The SC__SAVE_STATE indicates that a selection was 
made to save the UI State. The InfoCenter will then save the 
current UI state into this SelectionContext object by calling 
setUserlnterfaceState, described below. 

The SC__HIDE_UI indicates that a selection was made to 
hide the current user interface (UI) 

The setUserlnterfaceState method comes in two flavors: 
one method takes a UserlnterfaceState object, and the other 
an ActionDescriptor. Both methods will store a Userlnter- 
faceState object in this SelectionContext. A UserlnterfaceS- 
tate object has the following definition: 

public class UserlnterfaceState implements Serializable 

{ 

public UserlnterfaceSt a te( Action Descriptor 

actionDescriptor, int pageNumber) 
public UserlnterfaceSt ate( Action Descriptor action 

Descriptor) 
public String getActionDcscriptorID( ) 
public void setAction Descriptor(Action Descriptor 

action Descriptor) 
public ActionDescriptor getActionDescriptor( ) 
public void setPageNumber(int pageNumber) 
public int getPageNumber( ); 

} 

There are two constructors for a UserlnterfaceState: both 
take an ActionDescriptor, and the first form can also take a 
page number. The constructor without a page number sets 
the page number to -1 to indicate the default page in a panel. 

The getActionDescriptor method gets the stored Action- 
Descriptor in this UserlnterfaceState, which is set by calling 
the setActionDescriplor( ) method. The ID String of the 
current ActionDescriptor can be retrieved by calling the 
getActionDescriptorID( ) method. 
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The getPageNumber( ) method is used to return a page 
number in a panel to turn to, while setPageNumber is used 
to set that page number in a panel to turn to. 

The UserlnterfaceState uses the Java Serializable inter- 
5 face to implement its persistence. Only the action ID string 
and the page number are persisted, however. 

In step 704, in order to provide an InfoCenter UI, the 
selection object implements the Selection interface. The 
Selection interface methods provide the information that 
10 describes the applet. The selection interface may be imple- 
mented with the following methods: 

public interface Selection 

{ 

public ActionBarAD getActionBarAD( ); 
is public Object getOwner( ); 

public Component getComponent( ); 

public Commander getCommander(String 
commanderld); 

public UlCommander getUICommander(String 
20 commanderlD); 

public PropertyPanelAD getDefaultPropertyPanelAD( 

); 

public Locale getUILocale( ); 
public Locale getActiveLocale( ); 
25 } 

The getActionBarAD method returns the Action Descrip- 
tor which describes the action bar for the current selection. 

The ActionDescriptors define the contents, display and 
behavior of the action bar and its buttons and menus. These 

30 descriptors are described in greater detail hereafter. The 
return value from getActionBarAD is the Action Descriptor 
for-the default ActionBar for this selection. 

The getowner( ) method returns the owner of the selec- 
tion. This method can be used to delegate commands to the 

35 object who implements a particular interface. For example, 
in an applet, if a table were the selection and the print 
command was issued, the print comOmander would check 
whether the selection, i.e., the table, implements printable. 
Since tables don't implement printable, the commander 

40 would call se lection. getOwner( ), which returns the Apple- 
tObject. The getOwner method checks whether the selec- 
tionOwner implements printable. If so, the commander 
would then call the appropriate print interfaces on the 
AppletObject. Depending on an applet's granularity of 

45 selection, the commander may continue calling getOwner( ) 
several times until it either finds an object who implements 
the specified interface or until getOwner( ) returns null or an 
object that doesn't implement Selection. Alternatively, the 
getowner( ) may be implemented using the 

50 Beans.isinstanceof, Beans.getinstanceof methods. However, 
there are some convenience methods provided in the 
DefaultCommander base class which provide alternative 
ways to find a commander which implements a specified 
command. See the description of the 

55 walkSelectionHierarchy, walkVisualHierarchy and doCom- 
mandTo methods in the description of DefaultCommander 
in FIG. 5, hereafter. 

The getComponcnt( ) method is used by a Selection to 
indicate the Component that should receive user interface 

60 keyboard focus (hereinafter referred to as focus) when the 
InfoCenter wishes to relinquish focus. 

The getCommander( ) method is used when the Info- 
Center wishes to execute a command requiring no user 
interface, and the getUICommander( ) is used when the 

65 InfoCenter wishes to execute a command that requires a user 
interface. The InfoCenter uses ActionDescriptors to deter- 
mine which to call. 
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The getDefaultPropertyPanelAD( ) method returns the 
action descriptor for the default property panel for this 
selection. It is used when the InfoCenter currently is dis- 
playing a property panel is up and the user selects a new 
selection. A property panel for the new selection, should be 5 
shown at this time. If a property panel is showing and a new 
selection is received, the InfoCenter will ask the new Selec- 
tion for its default property panel action descriptor. It will 
then show the default property panel. 

The getUILocale( ) method is called to obtain the Locale 10 
for the current user interface. The implementer of selection 
can use this to control the Locale from which resources are 
obtained when displaying user interface. Locale information 
is used to present user interface for varying countries and 
languages. is 

The getActiveLocale( ) method is called to obtain the 
active Locale from the current Selection The active locale is 
used for all Locale information not connected to the display 
of the user interface, such as for sorting text or the display 
of currency, and so on. For example, if the UI Locale is 20 
French and the active Locale is German, then the user 
interface will appear in French, but currency will appear as 
German, and text will be sorted using the rules appropriate 
for German. 

In step 706, in the illustrative embodiment, the action bar 25 
contents, display and behavior are defined by a set of records 
known as Action Descriptors 808 and are shown in FIG. 8. 
Action Descriptors 808 may be implemented as a class 
which defines their Action Descriptors 808 as a static array 
of strings. Alternatively, these descriptors may be read from 30 
resource files. 

The set 802 of Action Descriptors 808 included in the 
applet UI is specified in the applet's User Interface by the 
applet designer. External application developers can cus- 
tomize the user interface of an applet by editing the Action 35 
Descriptor Set 802. 

ActionDescriptorSet 

An ActionDescriptorSet (ADSet) 802 is an object which 
contains a collection of action descriptors (AD) 808 and the 40 
resource information in resource bundle 806 that is associ- 
ated with the action descriptors. ADSets are used by Info- 
Center clients to load, store and manage a client's ADs. It is 
also integral to the IC customization features. The Ads 808 
in an ADSet 802 are accessed using the action ID for a given 45 
action descriptor as a key. An ActionDescriptorSet 802: 

Contains a collection of action descriptors 808 and the 
resource information in bundle 806 to resolve resource 
references in the action descriptors 808. 

Used by InfoCenter clients to load, store and manage a 50 
client's ActionDescriptors 808. 

An ActionDescriptor 808 is an object which describes: 
how to execute an action and the elements of the action's UI 
representation in the InfoCenter. Action execution is speci- 
fied by the type of ActionDescriptor 808, and if applicable 55 
certain fields of the action descriptor (see Format Of Action 
Descriptor Strings and Field Values For Different Action 
Descriptors). Each ActionDescriptor 808 has a reference to 
the ActionDescriptorSet 802 that created it. 

Actio nDescriptorSets 802 are stackable. When a request 60 
for an ActionDescriptor 808 is made, the ActionDescriptor- 
Set 802 looks for the specified ActionDescriptor 808 in its 
collection of ActionDescriptors. If it does not find the 
specified ActionDescriptor in its collection, it passes the 
request to its default ActionDescriptorSet 804. This enables 65 
two features: sharing common ActionDescriptors and imple- 
menting IC customization. 
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There are several types of action descriptors. The follow- 
ing diagram in FIG. 9 shows the relationship among the 
different types of action descriptors: 

That is to say: all ActionDescriptors 808 derive from 
ActionDescriptor. All collections of Action Descriptors 
derive from CollectionAD 810, and there are three such 
classes: ActionBarAD 814, GroupControlAD 816, and 
PopupMenuAD 818. All Action Descriptors 808 for Com- 
manders derive from CommanderAD 812, and number 
three: BooleanPropertyAD 820, DirectCommandAD 822, 
and UICommanderAD 824. All Commanders with UI derive 
from UICommanderAD 824, and number two: Panellte- 
mAD 826 for panels, and QuickPickltemAD 828 for Quick- 
Picks., 

Each ActionDescriptor 808 is a String with the following 
format (<n> indicates a field, which can be any text): 
<1>=<2>, <3>, <4>, <5>, <6>, <7>, <8> 
The meaning of each field is described below: 
<1> Action ID is a string which identifies an action descrip- 
tor in an action descriptor set. (e.g. IDA CUT, IDA_ 
SAVE) 

<2> Action Type is a string which specifies the type of action 
descriptor this string describes, (e.g. direct, popup, 
propertypanel) 

<3> Commander Classname or Contents List — The mean- 
ing of this field depends on the type specified in field #2. 
For action descriptors which derive from CommanderAD, 
this field specifies a class name for the Commander to be 
used to execute the action. (e.g. 
lotus, fc.ichelpers. File Commander) For ColiectionADs, 
this field contains a vertical bar (D delimited list of Action 
IDs, This list of Action IDs describes which action 
descriptors are contained in the CollectionAD. (e.g. 
IDA_CUT|IDA COPY|IDA_PASTE) 

<4> Commander ID For Action — Commanders define IDs 
for all of the actions and properties it knows how to 
execute. This field contains the string version of this ID. 
This string is passed to the Commander. The Commander 
then returns a corresponding integer ID for the action. The 
integer ID is then used as the action identifier for the rest 
of the Commander interface, (e.g. ID__CUT, ID_PRINT) 

<5> Resource Reference For User Visible Name is a field 
that contains the reference into a resource bundle for the 
user visible name. The user visible name is the string 
which is displayed in the action bar or popup menu for the 
action, (e.g. IC_AD_STR_GRP_CUT, IC_AD„ 
STR_EDIT) (see Resolving Resource References For 
Action Descriptors) 

<6> Resource Reference For Image Filename is a field 
containing the reference into a resource bundle for the 
image filename. The image is only used when an action 
sits directly on the action bar. When an action is contained 
within a group control or a popup menu, this field is 
ignored, (e.g. IC_AD_IMG_SAVE, IC_AD„IMG_ 
OPEN) (see Resolving Resource References For Action 
Descriptors) 

<7> Resource Reference For UI Filename 
(PropetyPanclAD, CommandPane IAD , 
QuickPickltem) — The InfoCenter can host UI from' a 
client like a quickpick, a command panel, or a property 
panel. This UI is obtained from a UlCommander by 
providing an identifier to the UlCommander. 
Traditionally, this identifier has been a filename for the 
persisted version of a UI, namely a Bongo GUI file. Due 
to remnants of an earlier InfoCenter architecture, this field 
is a resource reference into a resource bundle, (e.g. 
I C__AD_G UI_TEXTSTYLE) 
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<8> Resource Reference For Long Description (Optional/ 
Not Implemented) — If bubble help is supported by the 
InfoCenter, this optional field can be added to an action 
descriptor to supply the text for the bubble help. This field 
is parsed and made available through the ActionDescrip- 
tor class, but it is not used in the current implementation 
of the InfoCenter. 
Each type of Action Descriptor 808 makes differing use of 
the fields in an Action Descriptor as follows: 

The ActionBarAD 814 record type assigns these mean- 
ings to the fields: 
• <1> ActionID 
<2> "actionbar" 
<3> Contents List 
<4> "null" 
<5> "null" 
<6> "null" 
<7> Not used 
<8> Not used 

The GroupControLAD 816 record type assigns these 
meanings to the fields: 
<1> Action ID 
<2> "group" 
<3> Contents List 
<4> "null" 

<5> User Visible Name (optional) 
<6> "null" 
<7> Not used 
<8> Not used 

The PropertyPaneLAD record type assigns these meanings 
to the fields: 
<1> Action ID 

<2> "panel" or "propertypanel" 
<3> Commander Classname 
<4> Commander ID For Action 
<5> User Visible Name 
<6> Image Filename (optional) 
<7> UI Filename. 
<8> Not used 

The CommandPanclAD record type assigns these mean- 
ings to the fields: 
<1> Action ID 
<2> "commandpanel" 
<3> Commander Classname 
<4> Commander ID For Action 
<5> User Visible Name 
<6> Image Filename (optional) 
<7> UI Filename 
<8> Not used 

The PopupMenuAD 818 record type assigns these mean- 
ings to the fields: 
<1> Action ID 
<2> "popup" 
<3> Contents List 
<4> "null" 

<5> User Visible Name 
<6> "null" 
<7> Not used 
<8> Not used 
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The QuickPickltemAD 828 record type assigns these 
meanings to the fields: 

<1> Action ID 

<2> "quickpick" 
5 <3> Commander Classname 

<4> Commander ID For Action 

<5> User Visible Name 

<6> Image Filename (optional) 
10 <7> UI Filename 

<8> Not used 

The DirectCommandAD 822 record type assigns these 
meanings to the fields: 

<1> Action ID 
15 <2> "direct" 

<3> Commander Classname 

<4> Commander ID For Action 

<5> User Visible Name 
20 <6> Image Filename (optional) 

<7> Not used 

<8> Not used 

The Boole anProperty AD 820 record type assigns these 
meanings to the fields: 
25 <1> Action ID 

<2> "boolean" 

<3> Commander Classname 

<4> Commander ID For Action 
30 <5> User Visible Name 

<6> Image Filename (optional) 

<7> Not used 

<8> Not used 

When an ActionDescriptor 808 needs to resolve a 
35 resource reference, it asks its ActionDescriptorSet 802 for its 
ResourceBundle 806 (FIG. 7) and accesses the resource 
through ResourceBundle API. 

For resourced URLs, the locale and resource base which 
are stored in the ActionDescriptorSet are used in conjunction 
40 with the ResourceBundle 1 s resource value for that key. 
As mentioned above there is a set of SharedActionDe- 
scriptors provided by the InfoCenter client helper code 
(lotus\fc\ichelpers\Sh*aredAction Descriptors.properties). 
This set is loaded by the InfoCenter module. Applet teams 
45 may reference records defined in the shared set in their menu 
or actionbar lists. 

There are three special descriptors defined in SharedAc- 
tionDescriptors.properties: 
ActionID Meaning 
50 IDA_SEP used in action bar lists to indicate that a visual 
separator should be placed between items. 

IDA MENU_SEP used in menu content lists to indicate 

that a visual separator should be placed between items. 
IDA_POPUPICON used to indicate the bitmapped image to 
55 be used for the icon for popup menus displayed on the 
InfoCenter. 

Several of the strings specified in the ActionDescriptors 
are user-visible. In the illustrative embodiment, the whole 
action descriptor set may be resourced to keep all the text, 
60 descriptors and gif file names together. 

In step 708 of the illustrative embodiment, the Com- 
mander and UlCommander classes provide the mechanism 
for translating the id-based information provided* by the 
InfoCenter UI to the applet code that handles a command or 
65 gets/sets a property. 

When a user clicks on an actionbar button, the InfoCenter 
will instance the associated Commander/UICommander 
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class by name. It then sets the selection object on the The getselection( ■) method returns the current selection 

Commander class. The selection object provides the hook object. 

into the Applet that the Commander needs. Then depending The getIDFromString(String idstring) method is called by 

on the action type, it either calls doCommand, get/ the InfoCenter to translate string-based ids to integer ids. 

setProperty or CreateUI 5 Applet-defined ids should be greater than or equal to zero. 

The designer's implementation of the Commander meth- int ID_CLOSE static integers provide default id's for 

ods can handle commands and property setting in any way standard panel buttons If a Commander class is derived 

selected by the designer. Preferably, however, the designer ^Pff^ommzn der then these ids may be used to 

calls into the applet using interfaces that can be exposed via P^^ 1 ^?^? ° f ^^^^ ^ 15 

• , , set to "OK , "CLOSE or "CANCEL . The button name 

the script model 10 may differ from the button label. 

The Commander interface is defined as follows: ^ e setSelection method fa called t0 xi the Se i e ction 

public interface Commander interface into a Commander. Similarly, getSelection 

i retrieves the last Selection interface received by call to 

public abstract Object doCommand(int id); setSelection. The InfoCenter listens on the InfoBus for 

public abstract Object doCommand(int id, Object arg); 35 Selection, and uses these methods to manage the current 

public abstract Object getProperty(int id), setCommanderOwner method identifies an Object 

public abstract void setProperty(int id, Object value); implementing the CommanderOwner interface. GetCom- 

public abstract Object getPropertyOptions(int id, int manderOwner retrieves the last CommanderOwner interface 

optionType); 20 passed to setCommanderOwner. CommandOwner is an 

public abstract int getIDFromString(String idString); interface describing services the owner (creator) of a com- 

nuhlic static final int UNKNOWN ID— 1 • mander can provide. This interface should be supported by 

public static nnal int UNKNOWN_ID— 1, ^ ^ provides the V{ con[GX{ for the 

public static final int ID_CLOSE=-2; and is defined as f ollows: 

public static final int ID__CANCEL— 3; 25 public interface CommanderOwner 

public static final int ID_OK— 4; { 

public abstract void setSelection(Selection selection); public java.awt.Frame getFrame( ); 

public abstract Selection getSelection( ); } 

. ,. „ u„. r„ Since getFrame returns an AWT Frame that the corn- 
public abstract void setCommanderOwner , & ,. . A . . , _ - 
r (C . n v m 30 mander can use to display dialogs, the InfoCenter sets itself 

* as the CommanderOwner, and uses a method in lotus. uti- 

public abstract CommanderOwner l.Util.getFrame to get the containing Frame for the Info- 

getCommanderOwner( ); Center t0 hosl all Commander-generated dialogs. The Com- 

} manderOwner interface is the way that the InfoCenter can 

The doCommand(int id) method is called when a user ^ control the hosting of ^ AWT dia i ogs . 

chooses a button or menu item whose type is "direct" or a UlCommander interface extends the Commander 

LotusCommandButton widget in a panel. The Commandld interface and provides the ability to display additional user 

string specified in the Action Descriptor is translated to an interface elements, i.e. panels and quick-picks. The UlCom- 

integer and passed as the argument. mander interface is defined as: 

The getProperty(int id) method gets the property value Mfc interface UICommander extends Commander 



from the applet. The widget name string specified in the 



Bongo .gui file is translated to an integer and passed as the ^ ... , t * ^ * 4 ITT 

. , & & , ™ . « . Jt . -j t , u public abstract Component createUI 

id argument. The method is used to set widget values when r /TTI „ , ^ r ' . . JX 

, 4 f r.i (UlCommanderOwner owner, String id); 

a panel is instanced or to get tbc current value of a boolcaD pubhc abstract void updateUI( ); 

property or toggling . 45 pubUc abstract void updateUI(int id); 

The getProperty(int id) method sets the property value in r . .. . . , 4 TII >~ v t < 

i . rnf • \ - 4 . j • *L ¥i public void destroyUHComponent c); 

» armlet The u/iHopt name ctnntr cnenrieH in the Rnnon r J \ i /* 



the applet. The widget name string specified in the Bongo 
.gui file is translated to an integer and passed as the id 



} 



argument. The method is used to set property values when The createUI (UlCommanderOwner owner, String id) 
a widget value changes or boolean button is clicked. m ? 1 hod 1S ™lled when a user chooses a button or menu item 

The getPropert y Options(int id, int optionType) method 50 ^°l e ^ * P*™ 1 . ° r quickpick The o Wner K the 
gets property information from the applet. The widget name InfoCenter and the id is the name of the UIFde specified in 
string specified in the Bongo .gui file is translated to an * he Actl0 u nl ?^ r 1 ,pt0r 11 f ^ the bu " 0n u ° r H ^ 

integer and passed as the id argument. There are several Bon ? 0 > * e U if 1,e W ! 11 b ? T ?/f 1 Fll u e ' but *c «terface doesn t 
optionTypes currently defined: re f ire l # ha |; ™ e ^UI( ) method is called to update the 

w T *r • i . L • ■ - * . l 55 values of all the widgets shown in the UI. The update UI(int 

MIN provide the minimum value for this property M) method ig caUed tQ update a parlicular widget shown v ^ 

MAX provide the maximum value for this property the V} The des troyUI(Component c) method is called to 

AVAILABLE specify whether this property or command release any resources that the component may be using. The 

is currently available (indicates whether to enable a parameter c is the component to be destroyed. 

widget or hot — also used for enabling/disabling action $0 

bar items and menu items) 
LEGALVALUES provide a list of values for this property; 

used for listbox widgets Elements of InfoCenter-Client Communication 

The setSelection(Se lection selection) method is called by 

the InfoCenter to provide the selection object to the Com- 65 InfoBus is used to share data among Java applications 
mander. The selection object provides the hook the Com- without a tight binding between the data provider and 

mander needs to the Applet. the data consumer. 



OVERVIEW OF COMMUNICATION BETWEEN 
INFOCENTER AND CLIENT 
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lotus.ic.client.Selection is an interface implemented by an 
InfoCenter client. An implementation of this interface 
provides information about the current selection in the 
client. 

lotus.ic.client.SelectionContext stores various parameters 5 
for a selection assertion are stored in an instance of this 
class before it is placed in a SelectionDataltem. 

lotus.ic.client.SelectionDataltem is a named InfoBus data 
item which transports the SelectionContext object from 
the client to the InfoCenter. 10 

lotus.ic.client.UserlnterfaceState generates objects used 
to store information pertaining to the current state of 
the InfoCenter's UI. Typically, this state is saved by a 
client so that the UI can be restored at a later time. 

lotus.ic.client.ICClientPreLoader is an interface imple- 
mented by an InfoCenter client. If a client would like 
the opportunity to preload certain resources to make 
their run-time performance more efficient, the client 
can implement this interface and set it in the Selection- 2 o 
Context object. During SelectionContext processing, 
the InfoCenter will exercise this interface to notify the 
client that preloading may begin. Typically, preloading 
should occur on a separate thread so that the InfoCenter 
is not blocked. 25 

lotus. fc.utiLRefreshThread is a thread used to process 
SelectionContext objects which are stored in the Selec- 
tionContext queue. 

lotus.ic.ICActionProcessor is a class used to queue 
actions which need to be executed on . the current 30 
selection. This class encompasses the storage of the 
actions and the thread handling for the queue. 

lotus.ic.client.ActionBarAD is a type of ActionDescriptor 
which defines the contents and the look of the Info- 
Center's action bar. The InfoCenter obtains the appro- 35 
priate action bar information by retrieving the Action- 
Bar AD from the client's Selection implementation. 

lotus.ic.client.PanelItemAD is a type of ActionDescriptor 
which specifies that ah action is to be used to launch an 
InfoCenter panel 

lotus.ic.client.Commander is an interface implemented by 
an InfoCenter client. The InfoCenter gets an instance of 
a Commander from the current Selection. This inter- 
face allows the InfoCenter to execute actions in the 
client. 

lotus.ic.client.UICommander is an interface implemented 
by an InfoCenter client. The InfoCenter gets an 
instance of a UI Commander from the current Selection. 
This interface extends Commander interface and is 50 
used to obtain UI which should be hosted by the 
InfoCenter. 

Description Of Initial Rendezvous Between 
InfoCenter and Client 

55 

An InfoCenter and a client achieve their initial rendez- 
vous via a named InfoBus using a named data item. The 
default value for the named InfoBus is "%LotusInfoCenter- 
Bus%". The value for the named data item is "%LotusSe- 
lection%". 60 

When a client is ready to surface its UI in the InfoCenter, 
it sets its relevant implementation of the Selection interface 
into a SelectionContext object. It then sets any other appro- 
priate parameters based on the desired behavior of the 
InfoCenter. The SelectionContext object is set into a Selec- 65 
tionDataltem object. Finally, the SelectionDataltem object is 
placed on the named InfoBus. 
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The InfoCenter registers with the named InfoBus as a 
listener for the named data item. In the event that a named 
data item was placed on the bus before the InfoCenter was 
created, the InfoCenter looks for any relevant data item 
objects during initialization. 

When a named data item is found by the InfoCenter, the 
InfoCenter extracts the SelectionContext object from the 
data item and processes the object. 

Determining The SelectionContext Type 

When a new SelectionContext object is received, the 
InfoCenter first checks what the type property of the Selec- 
tionContext object. There are three types: SC__NEW 

SELECTION, SC_SAVE_STATE, SC_HIDE„UI. 

If the type property is SC_NEW_SELECTION, the new 
SelectionContext is placed in the SelectionContext queue for 
normal processing. This type of property is used when, 
refreshing the InfoCenter UI, restoring a saved user interface 
state, or asserting to perform an action. 

If the. type property is SC_SAVE_STATE, the Info- 
Center saves the current state of the user interface in a 
UserlnterfaceState object which is set into the Selection- 
Context object. The SelectionContext object is not placed in 
the SelectionContext queue. The SC_SAVE„STATE type 
is used during task switching in the Lotus Workplace. 
Applets were responsible for saving and restoring their state 
during task switches. 

Finally, if the type property is SC_HIDE_UI, the Info- 
Center hides itself and clears its internal state. 

Description Of SelectionContext Queue And 
ICActionProcessor Queue 

There are two queues each with their own threads in the 
InfoCenter: 1) SelectionContext queue, and 2) ActionProc- 
essor queue. 

The SelectionContext queue queues SelectionContext 
objects and is serviced by the RefreshThread. However, this 
queue does not process all SelectionContext objects equally. 
There are two designations for SelectionContext objects in 
this queue: (1) with actions to execute and (2) without 
actions to execute. 

If a SelectionContext has an action to execute, the object 
is placed in a FIFO queue. All SelectionContext objects with 
actions are processed in the order that they are received. 
SelectionContext objects without actions are stored in a 
1 -element queue. If a SelectionContext object without an 
action comes into the InfoCenter and one of these already 
occupies the 1 -element queue, the new SelectionContext 
object replaces the current object. In the illustrative 
embodiment, all SelectionContext objects are processed 
before any without actions. 

Processing Of SelectionContext Queue 

Before a new SelectionContext can be processed, any 
pending actions on the current SelectionContext (SC) must 
be executed. Therefore, processing of a new SelectionCon- 
text blocks until the ICActionProcessor is empty. The first 
thing that happens when the new SC is being processed is to 
determine whether the client should be notified to preload 
any resources. This result is saved until later in the process. 
The client is not notified to preload at this point. Next, the 
new SC is set as the current SC and a determination is made 
to whether the new SC is null. If null, the state of the 
InfoCenter is cleared. If the SC is not null, the InfoCenter is 
made visible and processing of the client's Selection imple- 
mentation begins. 
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At this point, the action bar of the InfoCenter is updated. 
If the action bar which is showing does not pertain to the 
new selection, the action bar is updated using the Action- 
BarAD from the Selection. If the current action bar is valid 
for the new selection, the values for the action bar are 5 
refreshed. 

Next, the InfoCenter makes some decisions about Info- 
Center panels. An InfoCenter panel is a panel which is 
created by the client and is hosted in the InfoCenter's layout. 
Typically, these panels fall into one of two categories: 10 
command panels and property panels. Command panels are 
like dialogs. Their distinctive feature is that the values 
entered into this type of panel do not take effect until the user 
chooses an OK button (or some equivalent) on the panel. A 
property panel acts much like an InfoBox panel. The con- 15 
trols on this panel update the client immediately after being 
adjusted. 

With regards to SelectionContext processing, the Info- 
Center first decides whether the new SC has a Userlnter- 
faceState to restore, and, if so, the rest of the panel logic is 20 
skipped. If the SC does not have a UserlnterfaceState to 
restore, the InfoCenter decides whether the new SC has an 
Action Descriptor to execute and whether that ActionDe- 
scriptor is a PanelltemAD. If there is an Actio nDescrip tor 
and it is a PanelltemAD, the rest of the panel logic is 25 
skipped. If not, then the InfoCenter decides whether an 
InfoCenter panel is currently showing. If a panel is not 
showing, then the rest of the panel logic is skipped. If a panel 
is showing, the InfoCenter checks whether the current panel 
is supported by the new selection, and, if so, its values are 30 
updated and the rest of the panel logic is skipped. If it is not 
supported, the InfoCenter determines whether the current 
panel is a property panel. If it is not a property panel, the 
current panel is closed. If it is a property panel, the Info- 
Center will replace the current property panel with the 35 
default property panel for the current selection. The Info- 
Center gets the default property panel by retrieving the 
defaultPropertyPanelAD property from the client's Selec- 
tion implementation. This ActionDescriptor is used to 
launch the default property panel. 40 

If the new SC had a UserlnterfaceState to restore, that 
would be done at this point. Then, if the SC had an 
ActionDescriptor to perform, the action would be placed in 
the ICActionProcessor queue. 

Finally, if the InfoCenter determined that the client should 45 
be notified to preload resources, the client is notified at this 
point. This notification happens through the ICClientPre- 
Loader interface. If a client would like the opportunity to 
preload UI resources, the client can implement the ICCli- 
entPre Loader interface. This implementation is then set into 50 
the SelectionContext prior to selection assertion. The Info- 
Center gets the I CClientPre Loader implementation from the 
SelectionContext and notifies the client that preloading can 
begin. In general, it is recommended that the actual preload- 
ing of resources take place on a separate thread. Having 55 
finished processing the new SelectionContext, the Refresh- 
Thread returns. 

Processing Of ICActionProcessor Queue 

The ICActionProcessor queue is a basic FIFO queue. 60 
Actions are executed in the order that they are placed in the 
queue. When the queue is empty, the thread which services 
the ICActionProcessor queue waits. All actions are funneled 
through a central point in the InfoCenter where based on the 
ActionDescriptor type the action is dispatched to the appro- 65 
priate handler. A handler exists for every type of Action 
Descriptor. 



Some types of action execution require interaction with 
the client. This interaction takes place through the Com- 
mander interface. ActionDescriptors which derive from 
CommanderAD use the Commander interface to interact 
with the client. There are two types of actions which can be 
executed through the Commander interface: commands and 
properties. The Commander interface allows the InfoCenter 
to get/set a property's value, get a list of supported values, 
and determine if the property should be enabled in the UI. 
For commands, the InfoCenter can execute a command and 
determine if the command should be enabled in the UI. 

Sometimes an action requires even more information 
from a client. For instance, actions which launch user- 
defined UI must be able to obtain the UI from the client. This 
level of interaction takes place through the UlCommander 
interface. The UlCommander interface allows the Info- 
Center to obtain an AWT Component from the client which 
can be hosted in the InfoCenter's layout. Since the UlCom- 
mander interface extends Commander, all of the same 
functionality which is exposed through Commander is also 
available through UlCommander. 

A Helper for InfoCenter-Client Communication 

Much of the InfoBus communications associated with 
asserting a selection has been encapsulated in lotus.ic.cli- 
ent.ICClientHelper. This helper class allows a client to set a 
few parameters and exercise a few methods to perform 
selection assertion. 

Focus Issues 

Hence, a focus management system was created to cen- 
tralize focus dependencies. This centralization takes place 
through a focus proxy. When the InfoCenter receives focus 
for any reason, the focus is passed to the focus proxy. This 
proxy is represented by an interface, lotus. ic.ICPopupFo- 
cusProxy. This interface is implemented by a class, ICPopu- 
pFocusProxylmpl. This implementation takes an AWT 
Component which is the entity that actually retains the 
focus. 

AWT Window Considerations (Popup Menus & 
Quickpicks) 

AWT windows are used to host InfoCenter popup menus 
and quickpicks. Unfortunately, AWT window implementa- 
tions across platforms may be inconsistent. The InfoCenter 
identifies the current platform so that windows can be 
created appropriately. In most cases, windows can be created 
normally by instantiating a Windows object; however, NCD 
2,5 (and Window32 platform) and Sun's JavaStation both 
have issues with creating and showing windows. 

For NCD 2.5 windows needed to be created as early as 
possible. To do this, Window objects needed to be created 
before any other AWT Components and kept in a cache so 
that the windows would appear on top of the other compo- 
nents. Therefore, when running under NCD, the InfoCenter 
creates a cache of windows and performs some special 
initialization so that the Windows appear. 

The Sun JavaStation does not have the z-order problem. 
However, it does exhibit the problem with not appearing on 
the first show. .Therefore, the InfoCenter does not cache 
windows on the JavaStation, but it does perform the special 
initialization. 

Keyboard Shortcut Support 

Each client creates a table which associates a semantic to 
an ActionDescrip tor's action ID. The client then defines in 
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their resource bundle a mapping between the semantic and There are also two convenience methods provided that 

a locale specific key sequence. These are read into the Commanders can use to find an object that handles a 

lotus. ic.client.KeyEventTranslator. When a client receives a specified command. Both of these methods require that the 

key event, it is passed into the translator and an ActionDc- designer override doCommandTo in the defined commander 

scrip tor is returned. This ActionDescriptor represents the 5 class. 

action which should be executed. The client then uses ^ boolean walkSelectionHierarchy (int id) method 

lotus.ic.client.ICClientHelper to assert a selection to per- m . m ] e S er . ld w £ ic h is . th ^ Cbmmand Id and returns a 

r ^ tu/A.*, rt «n 0 ^n rt » A r <v™ iu„ boolean indicating whether it found a handler for the com- 

form an action passing the AchonDescnptor from the trans- maQd ^ ^ {hc Qwner ^ of ^ 

later. The InfoCenter will then act upon this new selection. Selection and then the visual hierarchy, calling 

10 doCommandTo, until doCommandTo returns true or it 

InfoCenter Customization reaches the top of lhe hierarchies . 

InfoCenter customization allows a DevPack developer to TJe boolean walkVisualHierarchy (Object object, int id) 

turn-off items in an applet's InfoCenter UI. For instance, m f mod W * ich Sb °^ be * OTm P onen < and an 

. . *_ * . . ' integer id which is the Command Id. It returns a boolean 

actions that appear in tte action bar or popup menus can be indicating whether it found a handler for the command. The 

removed using the ICCustomizer which is launched from method walks up the visual hi erarchy 0 f the object, calling 

TemplateBuilder. doCommandTo, until doCommandTo returns true or it 

The InfoCenter uses ActionDescriptorSets in a "stack- reaches the top of the hierarchy. (Note: walkSelectionHier- 

able" fashion. What this means is that if a request comes into archy calls walkVisualHierarchy.) 

an ActionDescriptorSet for a particular ActionDescriptor, it Tne boolean doCommandTo (Object object, int id) 

will look in its own hashtable. If it does not have the method takes an object and an integer id which is the 

requested ActionDescriptor, it passes the request onto its Command Id. It returns a boolean indicating whether it 

default ActionDescriptorSet. This continues until there are hand J ed th , e command. The implementation in DefaultCom- 

no more ActionDescriptorSets in the chain. mand u er alwa y^ returns false. If applets want to use this 

_ _ _ _ % . , , . r searching mechanism in their commanders they must over- 

The InfoCenter Customizer tool is used to achieve Info- 15 ^de this method 

Center customization. The InfoCenter Customizer tool The DefaultUICommander abstract class provides default 

retrieves an applet's design-time ActionDescriptorSet. implementations for the UlCommander updateUI methods 

When the user selects which items should not appear in the and provides two other useful methods: destroyUI( ) and 

InfoCenter UI, the tool creates a run-time ActionDescrip- getUIPanel( ). The createUI method is not defined in this 

torSet which has the design-time ActionDescriptorSet as its 30 class, but in a class that knows what kind of UI to create (see 

default. All ActionDcscriptors in the InfoCenter UI are BongoUICommander). 

organized by CollectionADs. CollectionADs are ActionDc- updateUI( ) calls the updateUI method on the current 

scrip tors which have references to other ActionDescriptors. panel. 

For instance, a menu is represented by a PopupMenuAD updateUI(id) calls the updateUI(id) method on the current 

where the references to other ActionDescriptors are used as 35 panel 

the contents of the menu. If the user turns off an item in the destroyUI( ) called by InfoCenter when a panel or popup 

menu, the tool creates a copy of the PopupMenuAD and ^ going away 

modifies its list of ActionDescriptors so that it does not get uiPanel( ) called by UlCommander classes that need 

contain the item or items which were turned off by the user. tQ t the wk) t va , ues djrectl from a , ^ fc 

rhe tool then places this new CollectionAD in the run-t,me 40 for tti , values that m ents t0 

ActionDescnptorSet. When the user is finished with the tool, commands rather than property values, 

the nin-time ActionDescriptorSet is serialized to an .ICC The BongoUICommander class extends DefaultUICom- 

"* e - mander and provides the createUI method that knows how 

Logic is built into LFCApplet to determine which Action- to create Bongo Panels. Most applet UlCommanders extend 

DescriptorSet to use. If a .ICC file is specified, LFCApplet 45 this class. 

deserializes the run-time ActionDescriptorSet. The ClipboardCommander class extends DefaultCom- 

mander and overrides doCommand to provide default han- 

Support Classes dling for cut, copy and paste commands. To use this class the 

rn 4 . . j rijri. selection, or an object in the selection owner chain, must 

THere are several classes that provide useful default ^ lement the lotus.fc.ichelpers.ClipboardUser interfaced 

behavior. These classes can be extended and just provide reference ^ needecUo the Action f ds> IDA _CUT, IDA_ 

applet-specific code. C0PY and IDA_PASTE from SharedActionDescriptor- 

DefaultCom mander — provides default implementations s.properties in the menu and actionbar descriptors of the 

for all Commander methods. While several of the default action descriptor set. 

implementations are empty, the following methods are use- $5 The TextStyleUICommander class extends 

ful for applet teams, BongoUICommander and overrides the get/setProperty 

setSelection set the member variable m_selection methods, and getPropertyOptions. It provides default han- 

getSelection returns Deselection dU °« fo J the foUowin g P ro P ert i^: 

¥r ^^ _ . ^ , _ , . FontName 

getlDFromStnng The default implementation handles the p 

strings CLOSE, OK and CANCEL. In addition, it will 60 £ 

search an array of strings and return the index into that 

array. To use this implementation, the commander class 

defines the id strings in a static array and defines the Italic 

associated ids to be the index into that array. getID- Color 

FromString will call a DefaultCommander class 65 Alignment 

method that you must override: getlDStrings. The To use the TextStyleUICommander class, a selection, or 

getlDStrings then returns the static array of strings. an object in the selection owner chain, must implement the 
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lotus. fc. style. TextStyle interface. The designer can add 
Bold, Italic, Alignment or Color buttons to your action bar 
by specifying the Action Ids, IDA_BOLD, IDA_ITALIC, 
IDA_TEXTALIGN and I D A_TEXTCOLOR from Share- 
dActionDescriptors.properties. If the default text style panel 
is used that is defined in textstyle.gui, the designer can also 
use the I D A__TEXTSTYLE action id specified in Share- 
dActionDescriptors.properties. 

Some applets may want to use commander classes pro- 
vided by the infrastructure team, but need to augment the 
behavior to handle additional commands or properties. 
Alternatively, the designer can modify the handling in the 
base class of one or more properties or commands. Rather 
than rewrite the commander from scratch, the designer can 
derive the commander from the one provided in lotus, fc.ich- 
elpers. There are a few considerations the client must 
consider when doing so. 

The InfoCenter will call super. getProperty or superset- 
Property for any properties handled by the superclass from 
the get or setProperty method. Similarly with doCommand 
and getPropertyOptions. 

To avoid id value conflicts, there must be a static final int 
defined which indicates the value of the last id used by the 
base commander class. For example, the ids used by the 
TextStyleUICommander are defined in lotus.fc.style. text- 
style. java. A special value, 
lotus. fc. style. TextStyle. TEXTSTYLE__LAST_ID, is 
defined that indicates the value of the last id used by 
TextStyleUICommander. The designer can define property 
and command ids in the default class by adding to that value. 

If the default getlDFromString and override getlDStrings 
are used, the id array used is merged in the base Commander 
class, with the static array to return the full set. For an 
example of a derived commander class, see lotus.wp.ui.WP- 
TextStyleUICommander. 

Panels with Tabs 



Command Panels 
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Many of the panels designed by Lotus for applets contain 
more than one page or tab. The designer can define a 
separate U I Commander class to handle the properties on 
each page. This is especially useful when a tabbed panel 40 
contains standard panels plus some applet-specific panels. 
The shared commander class can be used for standard tabs 
and the commander can be written to handle the properties 
on the additional panels. 

The new way to specify the commander for a page within 45 
a tabbed panel is to create a LotusCommandButton Widget 
on the. page with the following properties: 

name is COMMANDER. 

label is the name of the commander for the page. e.g. 
lotus.sheet.SheetCommander 50 
mode is invisible 

bounds are 0,0,5,5 (so they may be found) 



S ome panels in the UI are much like dialog boxes in suite 
appl ications, ine widgets in the p anel are not associate d 
witfi properties, but rather" provide ar guments to a command. 
To implement one of these p anels, one fflPst ~ 

1. use either standard or lotus-specific widgets for the 
arguments widgets 

2. name all argument widgets 

3. use a LotusCommandButton for the OK (or Done) 
button 

4. give the OK button a unique name for this command 
When the user clicks on the OK button, the InfoCenter 

calls the defined corrimander's doCommand method, pass- 
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ing in the id associated with the OK button name (as 
returned from getlDFromString). In a modified doCommand 
method, getUIPanel method can be called to get the panel 
object. The widget value for each argument widget can be 
obtained from the panel. 

S ame panels contain ajieJjQ£buttons which together act as 
a c hoice control. These buttons should be grouped in to a 
LotusButto nGroup Wid g et. The d efined commander is called 
at th e~"selPfoperty method for the group. Trie^value^ofl he 
wiaget is the name of the selected button widg et, ihe 
InfoCcfrt er-traBsIates the name of the jjOtusijuttonU roup- 
Widget via g etllJbromString so the user defin e^ commander 
m ust <be~ahle tn interpret Ihe butto n .name for the g roup 
wi3geTyaliije. 



Property Changes From the Applet 

When the user changes a property in the applet via 
direction manipulation fe.g. ctrl-Bto set text bold), the 
In foCenter must update itsUI to reflect the new state of the 
se!e^tion ; Currentlv. the way to inform the Jnfo.Center_of this 
change" js~to re-assert the .selectio n. 

Resource File Locations 

The set of shared .gui and .gif files are located in 
lotus\fc\ichelpers\res. The user should put the applet-specific 
resource files in a "\res" subdirectory of the directory where 
the user keeps the commander classes. 

In the action descriptors, the user can specify path loca- 
tions (relative to CODEBASE) for the Bongo .gui files 
(using 'V as a separator). However, this makes the action 
descriptors harder to read. If only the file name is specified, 
the BongoUIPanel code uses the following search method: 

Step 1. Search in CODEBASE, using the commander 
classname plus "res" 

Step 2. Search in CODEBASE again, using the classname 
of the commander's superclass plus "res" 

Step 3. Continue up the superclass hierarchy as described 
until one is found or it reaches the top of the tree. 

This way UI Commanders can use the .gui files of their 
superclass. Currently, gif files default to 
lotus\fc\ichelpers\res if no path is specified. 

As set forth previously, object-oriented technology forms 
the basis for the InfoBus architecture 200 of the present 
invention. For the purpose of the illustrative embodiment, 
components are essentially Java objects that conform to the 
Java Beans and Java specifications. 

A software implementation of the above described 
embodiments) may comprise a series of computer instruc- 
tions either fixed on a tangible medium, such as a computer 
readable media, e.g. diskette 142, CD-ROM 147, ROM 115, 
or fixed disk 152 of FIG. 1, or transmittable to a computer 
system, via a modem or other interface device, such as 
communications adapter 190 connected to the network 195 
over a medium 191. Medium 191 can be either a tangible 
medium, including but not limited to optical or analog 
communications lines, or may be implemented with wireless 
techniques, including but not limited to microwave, infrared 
or other transmission techniques. The series of computer 
instructions embodies all or part of the functionality previ- 
ously described herein with respect to the invention. Those 
skilled in the art will appreciate that such computer instruc- 
tions can be written in a number of programming languages 
for use with many computer architectures or operating 
systems. Further, such instructions may be stored using any 
memory technology, present or future, including, but not 
limited to, semiconductor, magnetic, optical or other 
memory devices, or transmitted using any communications 
technology, present or future, including but not limited to 
optical, infrared, microwave, or other transmission technolo- 
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gies. It is contemplated that such a computer program 
product may be distributed as a removable media with 
accompanying printed or electronic documentation, e.g., 
shrink wrapped software, preloaded with a computer system, 
e.g., on system ROM or fixed disk, or distributed from a 5 
server or electronic bulletin board over a network, e.g., the 
Internet or World Wide Web. 

Although various exemplary embodiments of the inven- 
tion have been disclosed, it will be apparent to those skilled 
in the art that various changes and modifications can be JQ 
made which will achieve some of the advantages of the 
invention without departing from the spirit and scope of the 
invention. It will be obvious to those reasonably skilled in 
the art that other components performing the same functions 
may be suitably substituted. Further, the methods of the 
invention may be achieved in either all software 15 
implementations, using the appropriate processor 
instructions,, or in hybrid implementations which utilize a 
combination of hardware logic and software logic to achieve 
the same results. Such modifications to the inventive con- 
cept are intended to be covered by the appended claims. 20 

What is claimed is: 

1. A method for providing a user interface to applet 
members within a Java virtual machine (JVM) having an 
information bus that allows direct communication and data 
sharing between applet members of the information bus, the 2 s 
method comprising the steps of: 

(a) making a general user interface a member of the 
information bus; 

(b) in response to an announcement from an applet 
member of the information bus, querying the applet 30 
member regarding all specified requirements for the 
user interface for the applet member; 

(c) transmitting to the general user interface the require- 
ments of the user interface for the applet member; 

(d) generating the applet member user interface based on 35 
the requirements transmitted to the general user inter- 
face and prior to any subsequent interaction with the 
applet member user interface by a human user . 

2. The method of claim 1 further comprising the steps of: 

(e) issuing a user interface change request by the applet 40 
member to the general user interface; 

(f) performing the change request upon the applet member 
for customizing the applet member user interface. 

3. The method of claim 1 wherein the general user 
interface is a base object and each applet member interface 45 
is an instance class of the general user interface base object. 

4. The method of claim 1 wherein step (d) includes: 
(dl) generating an action bar; and 

(d2) generating a plurality of menu items based on the 
requirements of the applet member. 50 

5. The method of claim of claim 4 further comprising: 
(d3) implementing a set of graphical user interface panels. 

6. The method of claim 4 wherein the action bar is 
designed for a work file environment. 

7. The method of claim 4 wherein the action bar is 55 
designed for a web browser environment. 

8. The method of claim 4 wherein the step (d2) includes: 
(d5) preparing a popup menu for a portion of the plurality 

of menu items. 

9. The method of claim 1 wherein step (d) comprises: 60 
(d4) invoking selected action descriptors to generate the 

applet member user interface. 

10. The method of claim 1 wherein step (d) comprises: 
(d6) generating a quick -pick item to select a widget. 

11. A computer program product to provide a user inter- 65 
face to applet members within a Java virtual machine (JVM) 
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having an information bus that allows direct communication 
and data sharing between applet members of the information 
bus the computer program product comprising computer 
usable medium upon which program code is stored, com- 
prising: 

program code to make a general user interface a member 
of the information bus; 

in response to an announcement from an applet member 
of the information bus, program code to query the 
applet member regarding all specified requirements for 
the user interface for the applet member; 

program code to transmit to the general user interface the 
requirements of the user interface for the applet mem- 
ber; 

program code to generate the applet member user inter- 
face based on the requirements transmitted to the 
general user interface and prior to any subsequent 
interaction with the applet member user interface by a 
human user. 

12. The computer program product of claim 11 further 
comprising: 

program code to issue a user interface change request by 
the applet member to the general user interface; 

program code to perform the change request upon the 
applet member for customizing the applet member user 
interface. 

13. The computer program product of claim 11 wherein 
the general user interface is a base object and each applet 
member interface is an instance class of the general user 
interface base object. 

14. The computer program product of claim 11 wherein 
the generating program code includes: 

program code to generate an action bar; and 
program code to generate a plurality of menu items based 
on the requirements of the applet member. 

15. The computer program product of claim 14 further 
comprising: 

program code to implement a set of graphical user inter- 
face panels. 

16. The computer program product of claim 14 wherein 
the action bar is designed for a work file environment. 

17. The method of claim 14 wherein the action bar is 
designed for a web browser environment. 

18. The computer program code of claim 14 further 
comprising: 

program code to prepare a popup menu for a portion of the 
plurality of menu items. 

19. The computer program product of claim 11 wherein 
the generating program code comprises program code to 
invoke selected action descriptors to generate the applet 
member user interface. 

20. The computer program code of claim 11 further 
comprising program code to generate a quick-pick item to 
select a widget. 

21. A method for dynamically generating a user interface 
in a network computer environment comprising the steps of: 

receiving an announcement of a user object selection from 
an application; 

querying the selection object for a user interface descrip- 
tion; 

graphically displaying an action bar based on the user 
interface description transmitted to a general user inter- 
face and prior to any subsequent interaction with a 
human user; and 

responding to the human user 

***** 
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